Skip to content

Conversation

nickrobinson251
Copy link
Member

@nickrobinson251 nickrobinson251 commented Jan 15, 2025

@nickrobinson251 nickrobinson251 force-pushed the v1.12.0-DEV+RAI branch 4 times, most recently from 966538b to 9da665d Compare January 29, 2025 13:01
@DelveCI DelveCI force-pushed the v1.12.0-DEV+RAI branch 7 times, most recently from 1cff7d7 to 1e6e20d Compare February 7, 2025 00:28
@DelveCI DelveCI force-pushed the v1.12.0-DEV+RAI branch 5 times, most recently from 02e0f68 to 35024c5 Compare February 18, 2025 00:28
@DelveCI DelveCI force-pushed the v1.12.0-DEV+RAI branch 4 times, most recently from fb189dc to 7e4f1cb Compare February 27, 2025 00:29
@DelveCI DelveCI force-pushed the v1.12.0-DEV+RAI branch 3 times, most recently from 7eb4dc1 to d4a2432 Compare March 9, 2025 00:27
@DelveCI DelveCI force-pushed the v1.12.0-DEV+RAI branch 5 times, most recently from f36b557 to 4abc802 Compare March 26, 2025 00:30
@DelveCI DelveCI force-pushed the v1.12.0-DEV+RAI branch 2 times, most recently from 9c3bd8a to 5edeae9 Compare September 3, 2025 00:30
Zentrik and others added 2 commits September 4, 2025 09:13
…uliaLang#58238)

`_aligned_msize` is now declared in mingw64's crt
(mingw-w64/mingw-w64@b40e24a)
as `_CRTIMP size_t __cdecl _aligned_msize(void *_Memory,size_t
_Alignment,size_t _Offset);`. Renamed our version to prevent the
conflict

(cherry picked from commit 2270fcd)
Keno and others added 23 commits September 5, 2025 14:33
This is an alternative to JuliaLang#59161, attempting to fix the same observed CI
behavior. I don't think JuliaLang#59161 is the best way to fix it, as the point
of these tests is to make sure that REPL completions looks up the PATH
internally. Calling the path update function explicitly defeats that
somewhat. The extra synchronization here to make this deterministic is
messy, but I do think it makes the test closer to real-world usage.

The core attempted fix here is to move the read of the PATH_ locals
inside `maybe_spawn_cache_PATH` into the locked region. If they are not
under the lock, they could be unconditionally overwritten by a second
call to this function, causing issues in the state machine. I do not
know whether this is the cause of the observed CI hangs, but it's worth
fixing anyway.

(cherry picked from commit 9a16119)
(cherry picked from commit 25a2c88)
Prevent transparent huge pages (THP) overallocating pysical memory.

Co-authored-by: Adnan Alhomssi <[email protected]>
Prepend `[signal (X) ]thread (Y) ` to each backtrace line that is
displayed.

Co-authored-by: Diogo Netto <[email protected]>
Alternative to JuliaLang#58146.

We want to compile a subset of the possible specializations of a
function. To this end, we have a number of manually written `precompile`
statements. Creating this list is, unfortunately, error-prone, and the
list is also liable to going stale. Thus we'd like to validate each
`precompile` statement in the list.

The simple answer is, of course, to actually run the `precompile`s, and
we naturally do so, but this takes time.

We would like a relatively quick way to check the validity of a
`precompile` statement.
This is a dev-loop optimization, to allow us to check "is-precompilable"
in unit tests.

We can't use `hasmethod` as it has both false positives (too loose):
```julia
julia> hasmethod(sum, (AbstractVector,))
true

julia> precompile(sum, (AbstractVector,))
false

julia> Base.isprecompilable(sum, (AbstractVector,)) # <- this PR
false
```
and also false negatives (too strict):
```julia
julia> bar(@nospecialize(x::AbstractVector{Int})) = 42
bar (generic function with 1 method)

julia> hasmethod(bar, (AbstractVector,))
false

julia> precompile(bar, (AbstractVector,))
true

julia> Base.isprecompilable(bar, (AbstractVector,)) # <- this PR
true
```
We can't use `hasmethod && isconcretetype` as it has false negatives
(too strict):
```julia
julia> has_concrete_method(f, argtypes) = all(isconcretetype, argtypes) && hasmethod(f, argtypes)
has_concrete_method (generic function with 1 method)

julia> has_concrete_method(bar, (AbstractVector,))
false

julia> has_concrete_method(convert, (Type{Int}, Int32))
false

julia> precompile(convert, (Type{Int}, Int32))
true

julia> Base.isprecompilable(convert, (Type{Int}, Int32))  # <- this PR
true
```
`Base.isprecompilable` is essentially `precompile` without the actual
compilation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.